ctbuilder: Parse lexerkind from grmtools section#551
Conversation
|
FWIW, I have been having some trouble with the patch after this one (applyting to Edit: Thinking on it the only alternative I could think of was making the type of This is also a bit non-linear that we'd use an entirely different code path when building from a string without |
|
This looks fine to me and I think we can merge it as-is? |
|
I think so, will have to revisit the parsing code but it's good to get the feature and it's tests in while that is being redone. |
2 participants
This adds
lexerkindparsing toCTLexerBuilder.This patch contains an interim change which modifies the manual grmtools section parser in
LexParserso that it recognizes thelexerkindfield, and doesn't produce an error.In a follow up, the plan is to remove that parser. We are most likely going to have to parse it twice, just so that the second parse can find the position into the source text where the grmtools section ends (Or alternately strip the header off of the source text passed to the
LexParser, but I think the former because we don't want users having to do that). But replacing the manual parser + the custom forcing mechanism, and passing the header through seemed like a change that was going to dwarf adding thelexerkindfield to the header.Let me know however if you would prefer those changes to be done all at once instead?